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ABSTRACT: This paper builds on a technical report written by Carl Hewitt and 
Henry Baker called "Actors and Continuous Functionals". What is called a 
"goal-oriented activity" in that paper will be referred to in this paper as 
a "transaction". The word "transaction" brings to mind an object closer in 
function to what we wish to present than does the word "activity". This 
memo, therefore, presents the definitions of a reply and a transaction as 
given in Hewitt and Baker's paper and points out some discrepancies in their 
definitions. That is, that the properties of transactions and replies as 
they were defined did not correspond with our intuitions, and thus the 
definitions should be changed. The issues of what should constitute a 
transaction are discussed, and a new definition is presented which eliminates 
the discrepancies caused by the original definitions. Some properties of 
the newly defined transactions are discussed, and it is shown that the results 
of Hewitt and Baker's paper still hold given the new definitions. 


This report describes research done at the Artificial Intelligence Laboratory 
of the Massachusetts Institute of Technology. Support for this research was 
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. Introduction 


A transaction corresponds to our usual notion of a suhcomputation needed for 
Mibrou.iines. It includes those events which occur because a certain request is made, up to 
and including the resultant reply. The notion ol a request, followed by steps leading io a 
reply, appears over and over again in many different kinds of programming applications. 
Recursive function invocation, data bases, and interactive systems, for example, each 
illustrate the need for the concept of a transaction. In recursive function invocation a 
request is made lor the value of some expression, and a reply is subsequently returned. 
When working with data bases, one often wishes to retrieve a piece of information and 
thus will submit a request. Here again, the activity involved in replying to that request 
constitutes a transaction. Interactive systems are really nothing more than a series of 
requests and replies-,. Lisp, for example, uses the classic "read-eval-print" loop. 

The concept of a transaction is therefore an important one, and is extremely 
useful in reasoning 'about sequential program semantics. We need to establish a robust 
definition of a transaction that applies to distributed systems as well, where many 
machines or processors interact through a network. Communication between processes is 
necessary lor concurrent programming to he uselul; thus we wish to construct and 
examine a definition of a transaction which can be used to reason about such inter-process 
communicaf ion. 


ii. Background 

Actors and events are the basic concepts of the actor theory. Actors 
communicate with one another by sending messengers to each other. Each messenger 
contains information which the receiving or "target" actor then acts upon. An actor may 
create another actor, in fact, most messengers (which are also actors) are created just 
before being sent off to another actor. An event occurs when a messenger arrives at its 
target actor. Often we use the notation: 


E: [T M] 


to mean that target!LI r T and messongertLI - M. 
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Actors which a von actor directly knows about are called its "acquaintances", 
for an event G, the "participants" of G are the target(E), the messenger(E), and the 
acquaintances of target(G) and of messenger! E). An actor maintains a vector of 
acquaintances, which may or may not change over time. It may pain new acquaintances (or 
foiget old ones) through the acquaintances of a message sent to it. An example of an 
actor whoso acquaintances change over time is a "cell". It has one acquaintance, and can 
receive either a "contents?" request, in which case it replies with its acquaintance, or a 
update request, in which case it forgets its old acquaintance and remembers the new one 
given <o it by the update request. The behavior of other actors whose vectors of 
acquaintances may change with time are given in [Hewitt and Attardi, 1978]. 


The significance of an event causing an actor to change its vector of 
acquaintances is that such actors therefore are "order-dependent". That is, the order in 
which they receive messages can effect the replies they send to these messages. Such 
actors are "serialised" so that they can assign an "arrival ordering" to their messengers. If 
the message of event IT, arrives at a serialized actor S before the message of event E 2 , 
then we write: 


I'S "> t'. 2 

Altolher type of ordering is the "activation ordering". If as a result of 
receiving a messenger M in an event E? the target actor sends another messenger IV1 2 to 
an.actor A, (hen \\ ? is said to activate E 3 where E 3 is the arrival of M 2 at A. We write: 

E 2 -act-> E 3 

The transitive closure of these two kinds of orderings is called the "combined 
ordering", and according to the above two examples we could write: 


E» > E. 




t 


II. Transactions 


!L i. Request and Reply Events 

In order to study transactions we must have a formal definition of a request an 
a reply. A request is simply the messenger in any event of the form: 

[ ... [request: ...,reply-to: c] ] 

where c is a continuation. The definition of reply as given in [Hewitt and Baker, 19T7] is: 


If an event F. is of the form 

[ ... <*""• [request: ,..,reply-to: c] ] 

then any event E* o( the (orm 

[c [reply: ...1 ] 

<Mc\i that E ( 7 ( 7 "yV will he said to be a reply to F.. 

t\Ve will frequently refer to an event whose messenger is a request or a reply as a 
request or reply event, respectively. We use the notation "reply(RQ)” to mean the event 
whose messenger is the reply of the request event RQ. This paper assumes that at most 
o,,c reply exists for each request.) But this definition of a reply is too strict. Consider 
the case in which a request is sent to a serialized actor X in event RQ. Suppose that 
he foie sending a reply, X demands that it receive "permission" to do so. Permission is 
grained m the'form of the receipt of a clock pulse, which may arrive before or after the 
receipt of the request event. Calling the event in which the clock pulse arrives at X 
event F, we have .Is: [X pulse]. The pulse allows the reply to the first message to be 
sent, and it arrives at the continuation in event RP, such that RP: [C [reply: ...] ]• 


RQ: [X [request: M, reply-to: C] ] 


<m x 

4- 


E: [X pulse] ~■ t‘7 1 .’("> RP: 


c /v/*v 


[reply: ...] ] 
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We sor that RQ >E.(7rf >RP. There is no activation ordering between RQ and RP* 
but RP should still constitute a reply to RQ. We therefore propose that the definition of 
reply he weakened to: 

If an event E is of the form 

[ ... [request: reply-to: c]] 
then any event E’ of the form 

[c 0~ [reply: ...]] 

such that E—>E’ will be said to be a reply to E. 

By changing the requirement of an activation ordering between the request and its 
associated reply to a combined ordering, we allow events which are ordered by arrival 
ordering to enter the path between request and reply. 


II. ii. Redefining Transactions 


Hewitt arid Baker’s definition of a transaction (given this paper’s assumption that 
at most one reply exists for each request) is: 


transaction(RQ) 55 RQ—> H —>reply(RQ) 
where RQ is an event whose messenger is a request. 


Intuitively, a transaction is an attempt to characterize the notion of a process in 
conventional programming languages, since only those events which contribute towards the 
request’s reply are included in the transaction. 


For example, consider an event RQj in which a message M arrives at a serialized 
actor X with continuation C, that is, RQ j: [X [request: M, reply-to: C] ]. Let X 
then receive a second message (VP, such that RQ 2 : [X [request: NT, reply-to: C’] ]. 
X replies to IVT first by sending R’ to the continuation C\ It then replies to M. The 
following events and orderings are relevant. 







RQ i: [X [request: M, reply to: C] ] 
RQ 2 : [X [request: IVT, reply-to: C’] ] 


HQ, -<7./r x - > KQ Z 
RIQ: [O’ R’] 

IU 1 ,: [C R] 

RQ | -act- > RP | 

RQ ? -act-> RP 2 


RQ,: [X [request: M, reply-to: C] ] 

I 


act-> RP,: [C R] 


any 

I " 

v 


RQ 2 : [X [request: NT, reply-to: C’] -act-> RP 2 : [C’ 


Now, transaclionlRQ,) = {RQ,, RP,}, and transaction(RQ 2 ) = {RQ 2 , RP?)- Although 
RQ i — >RQ;j, RQ 2 is not an element ol transaction(RQj), because it is not true that 


A, 


RP,. 


* 

However, as originally pointed out by Craig Schaffert, we note that a 
discrepancy can arise with this definition. Consider the case in ILL above in which a clock 
pulse was used to activate the reply to a request. According to Hewitt and Bakers 
definition ol a transaction, Iransaction(RQ) = {RQ, E, RP}* But if the clock pulse arrives at 
X before RQ, we have the following situation: 

E -<7/7 X ~> RQ ~act~> RP 

Now transaction!RQ) = {RQ, RP}. This raises several questions concerning just what 
should he included in a transaction. Should F be included in the transaction in either case? 
Should it not? Should the whole computation fail to be recognized as a transaction? 




■~V '*■ IfiHB 
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In keeping with our intuitive* discussion of transactions, it seems that wo 
shouldn't throw out the whole computation, but we must now decide whether E should he 
included or not, and in either case, its inclusion or exclusion should be consistent and not 
dependent on the arrival ordering of E. 


Carl Hewitt has proposed that those events which are not request events or 
reply events (where a reply is extended to include complaints), should not be allowed to 
be members of any transaction. This constraint is in keeping with our concept of a 
transaction as that "thing” which models the classical notion of a process as a set of 
nested request events and events which reply to those requests. 


Adding this constraint to our definition of a transaction, we see that in order to 

determine whether E should be included in transaction(RQ), we must know whether it 

constitutes a request event or not (clearly it is not replying to X). If E is not a request 
event, then E will not be a member of transaclion(RQ) regardless of where it comes in the 
arrival ordering of X with respect to RQ, However, if E is a request event, it necessarily 
has an associated reply event. We will assume then that there is an event R such that R = 
reply!E). We can now put some constraint on R in order to include or exclude E (arid R) 

from tran: action! RQ). Following our intuitions (this is a definition, after all), we add the 

constraint that if E is a request, in order for E to be an element of transaction(RQ), 
K.->roply(RQ). More formally, we now have: 


l or some request or reply event E’, E’ < transaction(RQ) iff 

RQ - >FQ FT.>roply(RQ), and if E’ is a request event, 

then reply(E’)—>reply(RQ). 


What this meins is that.if a request event is to be part of a transaction, its associated 
reply event should be also. For the clock pulse example then, transactionlRQ) ~ {RQ, RP} 
where E is not included at all, since E is neither a request nor a reply event. Note that 
since we leave added constraints to the definition of transaction but not eliminated any,- 
that no event which was not part of a given transaction will now be defined to be. We 
have only eliminated certain "ad hoc" events from some transactions. We will examine 
later how this effects some of the results presented in [Hewitt and Baker, 197S]. 
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II. iii. Properly Nested Transactions 


We would now like to prove some properties of these transactions. In 
particular, it would be nice to be able to say that transactions are "properly nested". That 
is, that two transactions are either disjoint, or that one is a subset of the other. 
I infor t unit"!y, a counter example follows. 

Consider (he following event network and its associated orderings (Where the 
RQ’s are request events, the RP’s are reply events, and the E’s are neither. RP’s 
correspond to the RQ with the same subscript): 


RQ, 


kq 2 

RP, 

-act 

-> e 3 , 

RQ?' 

-act - > 

RQ 3 , RQ, 

E, • 

■arr* 

->e 3 

rq 3 

~aci-> 

rp 3 

E? - 

arr Y, 

-> E, 

RQ/. 

-a c(~y 

RP, 

e 3 

- act- 

> RP j 

RP- - 

-act- > 


E, 

-act- 

> rp 2 




act 

-> E 

1 


U C f 


RO 


■act- 


RO? 

\ 


au 



I 

arr, 


act-> RPo act-> E 3 -act-> RP j 

X 


rq 3 

RQ/j -act-> RP/j N mrf~> E 2 


arr x 

\ict~> Eq -act-> RP 2 


Wo v/i$h (o dot ermine which events arc members of trans^ctior»(RQ j) and which 
are members cl l ransactiordRQQ. I ransaclion(RQj) consists of RQj (obviously), hut not 
K(Q> ? cince R 1 Q - reply(RQo) has no ordering with respect to RPj “ repty(RQj). RQ 3 and 
KC)^ are both elements, since they are ordered with respect to RQj and RP), and their 
respective replies precede RPj. Then their replies RP 3 and RP 4 are also members. Ej 
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tin our,h r 4 u c not member?, of iransactionfKQ,) since they are neither request events nor 
to ply events. 1 inCiv, HP, is a member of transactionlRQ,). Therefore, transaction(RQj) = 
iKQ) ,, HQ;;, KQ/,, RIQ, RP„, RP,}. Similarly, lransaction(RQ ? ) = {RQ ?> RQ 3 , RQm RP 3 , RP«, 
RP,h 


The intersection of transactionlRQj) with transaction(RQ 2 ) consists of four 
event'-;, RQ (1 , RP ;j , RIQ;, and although this set is not a transaction itself, it consists 

of the union of two transactions. (It is possible to show that the intersection of two 
t ran- -actions is always equal to the union of some number of other transactions.) However, 
transaction!RQ,) is clearly not contained in transactiori(RQ 2 ), nor is transaction(RQ 2 ) 
contained in t ransact ton(RQ) i). 


Well, all is not lost, for we <an prove at least a slightly weaker properly, 
though one which is still quite useful. though we can not show that given any two 
transactions with at least one event in common, one transaction must be contained in the 
other, we can show that if a request event RQ is an element of transaction(RQ’), then 
(ransact ion(RQ) c transaction^ Q’). This is called the Law of Containment for 
Ti (insertions. 


Assume that E < transaction(RQ). To show that E < transaction(RQ’), we must 

show 


Coal 1: RQ’— >E—>reply(RQ’) 
and if E is a request event, that 

Goal rcply(E)—>reply(RQ’). 
Since I. 1 (ransaction(RQ) we have: 

RQ —>E—> reply! RQ) 

and since RQ 1 (ransaclionlRQ’k 

RQ’— >RQ—>reply(RQ)—->reply(RQ’). 







RQ’.->RQ—>E—>rop!y(RQ)—> reply! RQ’) 

Tin).-; RQ)’ • F— >t eply(KQ) ? ), which proves Goal 1. 

Assume 1:’ is a request event in order to prove Coal 2: 

reply (El-—>rcply(RQ’). 


Since 1. - tr ansaetion(RQ)) then 


reply (E)—> reply(RQ), 

and since RQ) < transact ion(RQ’), and RQ is a request event, 
we know 

reply! RQ). >repl y (RQ’). 

Thus repivS Is) — >repIy(RQ)’). [Done] 

Ilk (Continuous Functionals 
III, n (Continuation Ordering 

Before we go on, let’s briefly characterize those events which we have 
eliminUed from transactions. First of all, we have eliminated from transactions all those 
events which are neither request nor reply events. Secondly, we have eliminated all those 
request events whose associated reply events do not also participate in the transaction, 

Hewitt and Baker have defined a third ordering on events called the 
continuation ordering. In this ordering, F.j - cont~> E 2 if 1) there is some transaction c/ 
such that I,, and K ? are both members of w, and 2) Ej ~—> E 2 . Our redefinition of 
transaction affects this ordering to the extent that now if Ej ~cont-> E 2 ? wc * tnay 
automatically conclude that E| arid E 2 are either request or reply events since no other 
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type ol event may he art element of some transaction, and furthermore, given the ordering 
HQ] -cevt-> HQ ?) we can conclude reply(RQ?) -cont-> reply(RQj). It is also the case that 
some continuation orderings that once held between two events may no longer hold, since 
some events have been eliminated from transactions. But no additional continuation 
orderings will hold due to the redefinition of transaction. 

111. ii. Fork and Join Behavior 


The fork and join behavior discussed in Section IX of [Hewitt and Baker, 1975] 
holds up beautifully under the new definition of transaction, as long as no join occurs 
without a previous fork first providing the components of the join. This prerequisite is 
easy to fulfill, however, since the classic notion of a process implies that that is always 


the case. 


111. iii. Procedures and Mathematical Functions 

The definition of a procedure as given in [Hewitt and Baker, 1975] requires that 
1 ) all events involved in the procedure are either request or reply events, 2) there is at 
most one reply event (or each request event, and 3) the transactions are properly nested. 
Thai is, for any two transactions in the procedure, either one is a proper subset of the 
other, or they are disjoint. 


We wish to show that any transaction which was a procedure under the old 
definition is still a procedure under the new definition. That is, we wish to show that any 
event which was eliminated from a transaction by the new definition of transaction would 
not have passed as an event which could he part of a procedure anyway. If we can do this, 
then (he results given in [Hewitt arid Baker, 1975] for continuous functionals will still hold, 
smee they are based on actors which behave like mathematical functions, and mathematical 
functions depend on procedures for their definition. 




Wo have already characterized the events which were eliminated from 
transactions. Those .which are neither request nor reply events can not be part of a 
procedure under the first restriction. I hose request events whose corresponding reply 
events were not part of the transaction cannot he part of a procedure either, under the 
following reasoning. Assume the existence ot a request event RQ which is a member of 
t ransactionUv), but whose reply HP is not. Then RQ is also a member of transaction(RQ), 
as is its reply, HP. Then transaction(R) and transaction(RQ) are not disjoint in that they 
both contain RQ, but there is no containment since RP is not an element of transaction(K) 
(therefore transaction(RQ) is not contained in transaction(R)), and since K—~>RQ, R 
cannot he an. element of transac.Cion('RQ) (therefore transaction(R) is not contained in 
transactioii(RQ’i). Thus, no such transaction would pass as a procedure anyway. 

Thus, even with the new improved definition of transaction, we can still show 
that if an actor behaves like a mathematical I unction, then it is the limit of a continuous 
functional m the sense of Scott. It remains to be seen if anaUgous results can be shown 
to hold true for order-dependent actors. 


IV. Conclusions 


We leave uncovered two "hugs” in the [Hewitt and Baker, 1975] paper, one with 
the definition of "reply”, and one with the definition of a "transaction”. We proposed 
alternative definitions for both, and showed how these new definitions solved the 
discrepancies raised by the original definitions. Using the new definition of transaction, 
the Lauv of Containnumt for Transactions was proved, and the definitions of a procedure 
and a mathematical function wore shown to hold true. Because these definitions held, we 
were able to maintain the result that if an actor behaves like a mathematical function, then 
st is the limit of a continuous functional in the sense of Scott. 
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V. put hi p Work 

W'p h.\ve no( yet discussed tlu> uniqueness of replies, or indeed how multiple 
replies might effect the definition of a transaction. Although normally a request has only 
one r oply , if is conceivable that an actor might have a behavior that causes multiple replies 
to he sent in response to some request. 
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